There is a device driving system in which a host computer sends a command to a plurality of I/O nodes that drive an I/O device, and each of the I/O nodes that has received the command interprets the command and drives a corresponding I/O device.
However, in this method, if a processing flicker occurs on a host computer, that flicker is directly transformed into a flicker of a command issue time, causing it hard to issue a command at a precise time.
Also, since a communication channel inevitably has delay, it takes some time for a command to reach the remote side (an I/O node). Furthermore, there is often a flicker in a delay time of a communication channel, causing a flicker in the time in which a command reaches a remote side. If a device is driven by a software process or the like at a remote side, this flicker in a processing time at a remote side takes a form of a flicker in a device driving time.
Particularly, when a temporally-continuous control is performed, since each I/O node operates with its own internal crystal oscillator, time errors (caused by a frequency error of a crystal oscillator) accumulate, causing an operation timing error between nodes to increase with time.
Furthermore, in a traditional method, although data to be output is directly written to an output target device, since driving timing of an output device is generated by a CPU, time accuracy is low.
Also, in a traditional method, an intended frequency is obtained by dividing a frequency of a crystal oscillator that each node has. However, just dividing a frequency of an oscillator causes a phase to be uncertain, and there is also a problem that frequency errors of a crystal oscillator accumulate.
For a traditional point-to-point communication, as represented by an Ethernet®, a star topology is generally used. In this case, since data processing is performed on a communication frame basis, and transmission of a communication frame is performed in a store-and-forward manner, a whole communication frame needs to be received at a hub before data transfer from the hub to a neighboring node can be started. Also, timing at which each node generates a communication frame is not controlled.
This star topology has a disadvantage that an amount of wiring becomes large. Also, since an Ethernet has only one check code for a whole frame, it cannot be determined whether an error exists or not until a whole communication frame is received, and in order to rewrite the content of a communication frame and transmit the communication frame, a sequence of receiving a whole communication frame, rewriting the content of the communication frame, and sending the communication frame is needed. Thus, it takes a lot of time to pass through a node. Also, since timing at which a communication frame is generated is not controlled, there is a problem that it is not possible to ensure that a communication frame reaches the remote side within a given time.
Furthermore, in a traditional method, a communication delay is measured by sending a communication frame back and forth between the nodes at which a communication delay is to be measured. In such a measuring method, although a communication delay between two points can be measured, a communication delay at an intermediate point between the two nodes cannot be measured, so measurement needs to be iterated as much as the number of nodes that are needed.
[Patent Document 1] Japanese Patent Publication No. 51-13974